home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Apple II Sample Code / MPW IIGS SC / SC.021.Dynamo / Dynamo 3.0 Information < prev    next >
Encoding:
Text File  |  1990-04-10  |  3.5 KB  |  75 lines  |  [TEXT/MPS ]
  1. Some new stuff and some cool ideas:
  2.  
  3. If you are familiar with previous versions of Dynamo, you will see that a
  4. number of things have changed and have been reorganized.  The structure is
  5. more conducive to multiple-project development.  Since Dynamo is localized
  6. and the include files are available to AsmIIGS just like other include files,
  7. Dynamo version control is easier.  It is no longer so tempting to make a
  8. simple custom change to the Dynamo run-time for just one application, and
  9. therefore end up with multiple versions of Dynamo for different projects.
  10.  
  11. Another big change is that the source code for BUILDAPP.SYSTEM is now
  12. included.  This is so that extensions in the application build and launch
  13. process can be done by others to better suit their needs.  Currently,
  14. BUILDAPP.SYSTEM simply moves the code to the bank and memory location
  15. described in the build script.  Some more complex methods might be needed
  16. for more complex applications.  An application may need overlays, for
  17. example.  There may be two blocks of code that actually need to run at
  18. the same location, just at different times.  A revised BUILDAPP.SYSTEM
  19. could put these so-designated segments in auxiliary memory, and then the
  20. application could move them to main memory when needed.
  21.  
  22. For example:  Here is a simple idea for an overlay system:
  23.  
  24. BUILDAPP.SYSTEM could move designated files to aux ram when it is moving
  25. segments around at application launch time.  This could even be done by
  26. using ProDOS to save the range of memory to /RAM5.  When the main
  27. application needs the code segment, it could simply use ProDOS to load it
  28. into main memory.
  29.  
  30. Here's a reasonably simple approach to overlays:  When you want to call
  31. a segment of code that may or may not be in main memory, do a JSR to 
  32. an overlay management routine.  (Dynamic segments kind of work this way
  33. on the IIGS.)  The code would look something like:
  34.  
  35.         sec                     ;Input for overlay code.
  36.         lda     value           ;Input for overlay code.
  37.         ldy     value+1         ;Input for overlay code.
  38.         ldx     mode            ;Input for overlay code.
  39.  
  40.         jsr     overlay
  41.         dc.b    jiffyCoolCode   ;Segment # we want to call.
  42.  
  43. The overlay manager would first save the registers and processor status.
  44. Then it would use the return address on the stack to figure out where the
  45. jiffyCoolCode segment number is in memory.  It would then get this byte
  46. from memory.  Once this is done, the return address would be incremented 
  47. by 1 and pushed back onto the stack.
  48.  
  49. Now that we have the overlay segment #, we would use this to load the
  50. segment from /RAM5.  Once it is loaded, the registers and processor status
  51. would be put back to what they were when the overlay manager was called.
  52. Once this is done, the overlay manager would jump to where the code was
  53. loaded.
  54.  
  55. A little more logic could be added to see if the code segment requested
  56. is already in main memory.  (Old segment # = requested segment #.)  If
  57. it is, then the loading of the code could be skipped.
  58.  
  59. As you can see, doing overlays isn't so tough after all.  A simple
  60. system like this can really free up a lot of main ram on an Apple II.
  61.  
  62. For more readability, a macro could be used to call the overlay code.
  63. The call might look like:
  64.  
  65.         _jsr    jiffyCoolCode
  66.  
  67. The macro would expand to the calling convention shown above.
  68.  
  69. Any rate, given that BUILDAPP.SYSTEM isn't the final solution for
  70. everybody, I supplied the code so that everybody could change it
  71. if they wanted to.
  72.  
  73.  
  74. Eric Soldan, Apple II DTS
  75.